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SYSTEM AND METHOD FOR INTERFACINO MANUALLY CONTROLLABLE 
INPUT DEVICES TO A UNIVERSAL COMPUTER BUS SYSTEM 

BACKfiROTfND HP THE TMVPMTffYM 

1. Field gfthdnyemion 

This invention relates to the transfer of input data from manually controlled 
devices to computer systems, and more particularly to systems and methods for 
inexpensively and adaptively interfacing between one or more types and 
configurations of input devices and a host via the Universal Serial Bus ("USB* 9 ) 
structure and protocol. 

2. Background nf the Prior Art 

In the earliest versions of computer architecture, a computer or other central 
processor was connected to operate with one or a number of input, output, and storage 
devices, each operating in accordance with its own peripheral unit properties and 
specifications, including data rate, data format and prescriptors, directionality, 
operating mode, interchange protocols and synchronichy. Since these systems were 
unitary in the sense that each computer with its associated peripherals stood alone, 
each peripheral was typically interconnected by an interface section. The circuits and 
software in the computer controlled data transfer, usually employing buffers. The 
overhead involved in coaction with the peripherals was a substantial but usually 
separate burden on the computer system. 

With the advent of the microprocessor, a more direct link could be established 
with some peripherals, because the microprocessor speed and often limited functions 
enabled h to be used to share some peripheral functions, whether input or output, as 
by sensing the keys actuated on a keyboard, and refreshing the display on a video 
screen. The peripherals, however; often had to be specially made or adapted for 
operation with the microprocessors. Different microprocessors and software 
approaches limited the fatcrehangeabiKty of peripherals and often required the use of 
special adapters and installation procedures. 

In the same era, communication systems were being expanded to function with 
different input and output mit*, including feagimll* mriiW^ keyboards and th e like, 
Telephonic digital communications principally involved the use of modems during 
line transmission and reception, so that farther hardware or software came into use in 
order for these functions to become h^eractive with posond computers. 

There is now a vast inventory of synchrooously and asynchronously operable 
peripherals and PC configurations, mass manufactured for the consumer market 
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There arc also an increasing number of wired and wireless communications systems 
and devices, many with adjustable human input devices. Low cost peripheral devices, 
such as keyboards, mouse devices, joy sticks, and touch screens, should be usable for 
both types of applications in the current and developing state of the art 

s Recognizing the need for a universal methodology upon which systems and 

peripherals can be built, a number of large organizations in the industry devised and 
accepted a standardized format known as the Universal Serial Bus ("USB"). This is 
based upon a particular architecture and protocol defined in a specification published 
as Specification Version 1.0 on January IS, 1996 by Compaq, DEC, IBM, Intel, 

10 Microsoft, and Northern Telecom. The USB enables "plug and play" attachment of 
one or a number of "devices" (which can be a single hardware component or a 
collection of hardware components, a defined function or a hub) for flow of 
communication between a source and a sink of information. Different speeds and 
band widths can be accommodated and control information, error correction 

IS information, and data transfer blocks are included and defined Thus, with host 
computer systems arranged to connect and function with prescribed connections and 
formats, system and device designers can address a wider market for hardware, 
including both PC and communication technologies. With this standardized but 
highly versatile contact, PC configurations can be changed and upgraded without 

20 requiring corresponding and resultant changes in communication links, software, or 
I/O devices. The USB overcomes the burdens imposed by disparities of speed and 
data rates, and provides a low cost, bi-directional low to mid speed interconn^ 
useful with a wide range of PC architectures. It enables devices and ports to be added 
with the desired "piugmd play* ease. 

25 In the USB approach, many human input devices are essentially passive, and 

must operate within the power limitations of the bus, and respond to requests for 
current data. WMfr fSmplifii* mpntering design in many respects, much more is 
involved if mass produced human input devices are to be attached inexpensively. For 
example, keyboard, mouse, and joystick devices will vary as to the number, 

30 •nmgffn"» t t H^gtmtinn of actuator elements. Even from the same vendor, one 
keyboard matrix may be different from others to meet specific needs. Human input 
devices may be asynchronous, such as a keyboard, or synchronous, such as a PS/2 
mouse. In addition, since programs inherently call for the key combinations, 
generation of meaningful data for transmission to a p roce sso r can require processing 

35 to determine the commsnd selected by the operator. It is particularly advantageous to 
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provide a unit which can perform legacy support allowing existing keyboard and PS/2 
mouse combinations to operate within die emerging USB interface construct 

It is desirable to provide a unit which can collect data from one or more human 
input devices of a number of different types with minimal modification to account for 
5 variables, so as to make it possible to achieve economics of scale. The variety of 
input devices, and input device types, and the specific demands imposed by the USB, 
however, present formidable barriers to achieving a low cost system which is capable 
of accommodating the di fferent variations used by peripheral device manufacturers, 
while functioning tn the USB system. 

10 SUMMARY OF THE INVENTION 

Systems and methods in accordance with the invention overcome the 
enumerated problems and satisfy the objectives by providing a low-cost, highly 
adaptable, interface which couples any of a number of di fferent keyboards and other 
devices to a Universal Serial Bus (USB), including those which comply with the USB 

15 protocol (USB-compliant) and those which do not comply (USB-incompliant). The 
interlace includes a degree of processing capability, in conjunction with power 
management, buffering, clocking, and other resources adjustable to the particular 
input devices. Based upon this common interface a peripheral or computer 
manufacturer can mass produce or utilize any of a number of human input device 

20 configurations with assurance thai the same low cost interface will enable the devices 
to function in the USB environment In one example, an interna! processor is coupled 
to a serial EEPROM or other non-volatile memory, to a keyboard engine including a 
scanner, and to a mouse engine, with the matrix of an external keyboard being 
interconnected to the terminals of the scanner and the mouse engine being coupled to 

25 an external mouse device, which may be of the synchronous PS/2 type. Although the 
keyboard and moose have significantly different operative characteristics, flic data 
from both is requested under USB control, verified, buffered, and transferred, with 
device characteristics being taken into account in building the message frame 
sequences called for by the USB. To this end, die EEPROM is written for the 

30 particular input devices so as to incorpor a te configuration, vendor, and mapping 
sequences which enable the pr oc ess or to operate rapidly to map one or more actuated 
keys to a data output r e presenti ng the operator's command The serial EEPROM also 
operates to exchange information from the peripheral device to the host with a unique 
handshake protocol which prevents conflicts when accessing the EEPROM After 

35 verification that neither mechanical nor logical error has occurred, a message is made 
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available for transmission. A synchronous mouse device, internally clocked, provides 
control button actuation and XY position outputs serially on request The serial data 
is convened to parallel in the interface, verified using EEPROM data, assembled into 
one or more message segments, and thereafter transmitted in the USB format 
5 Provision is included for suspending operation to conserve power, in the event of 
inactivity for a specified time, for shutting power off to the peripheral devices in the 
event of demand beyond the USB specifications, and for arbitration of access to the 
system and correction of errors by the use of interrupts and resets, 

A novel system for deriving reliable information as to the operation of the 

10 keyboard, while accommodating different keyboard configurations, is provided by a 
keyboard scanning system in which a matrix of key positions is scanned along 
successive rows by energizing pulses. Within each pulse, the positions of the columns 
are successively scanned, to determine the intersection or intersections at which keys 
are actuated. These results are entered in a register, and the matrix is quickly 

15 rescanned, within a variably controllable time determined for that particular unit The 
results of die scans are used to assure that key vibration or bounce has not given an 
erroneous indication, and to ascertain whether a "ghost key" has been sensed. The 
serial EEPROM is accessed to map Ac sensed key locations for one or more keys into 
the value that is to be transmitted to Ae USB. 

20 The system is advantageously organized in the processor and engine 

configuration so that low cost standard and ASIC circuit units may be employed. It 
accepts the intermittent and relatively low and medium speed inputs from the 
operator-controlled devices and meets all the USB requirements for identification, 
error detection and correction, hand shaking, and message transfer. Thus, h is fully 

25 consistent with the objectives of the USB in terms of low cost, expandability and 
achieving true phig and play capability. 

BRIEF DESCRIPTION OP THE PttAWIMOS 

A better understanding of the invention may be had by reference to the 
following description, taken in conjunction with the acco mp anying drawings, in 
30 which: 

FIG. ] is a functional block diagram of the present invention; 
FIO. 2 is a hardware block diagram ofthe present invention; 
FIQ. 3 is an illustration of the data transfer timing with die serial EEPROM of 
the present invention; 
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FIGS. 4A through 4D are data diagrams showing data transfer modes of the 
present invention; 

FIG. 5 is a Mode diagram illustrating a specific embodiment of the interface 
between a keyboard and the present invention; 
5 FIGS. 6A-6C are flowcharts showing operations performed by the present 

invention to support a keyboard device and a PS/2 device, such as a mouse; 

FIGS. 7A-7F are flowcharts showing die operations performed by the present 
invention to scan the keyboard device; 

FIG. 8 is a flow chart depicting the serial interface operations for one 
10 embodiment of the present invention; 

FIG. 9 is a flow chart depicting the parallel interface operations for one 
embodiment of the present invention; and 

FIG. 10 is a flow chart depicting the infra-red interface operations performed 
in one embodiment of the present invention. 



is PKTATTfED DESCRIPTION OF THE INVENTION 

The examples depicted in FIGS. Ml are illustrative only, because the 
concepts, features, and techniques of the invention can be employed, in whole or in 
part, in many different combinations. Referring to FIG. 1, the specific 
exemplification shown is for interfering a computer keyboard 10 and a mouse device 

20 12 with a Universal Serial Bus (USB) 14 for communication with a host 16. The 
keyboard 10 may be any of a wide variety of conventional units available from 
various vendors, having keys arranged generally in rows (here taken in the vertical 
direction) and columns (hem taken in the horizontal tfirectionX so as to be definable in 
a matrix that can vaiy in both directions. Some keyboards, for example, define a 8 x 

23 16 or 8 x 17 matrix, some may have 8 x 18, and in some cases a given column (e£. 
17) is not used. The keys, used singly or in combination, define the command or 
input desired by toe operator, and tins translation also is not uniform. 

Hie mouse device 12 in tins example is a synchronous PS/2 device of 
conventional form, having two control buttons, X, Y Incrementor outputs representing 

30 mouse movement, and its own internally clocked microprocessor. The mouse device 
12 provides a serial output «ynt«imig the information generated by operator control 
and movement The USB 14 Is ihown only generally, as is the host 16, since it is not 
necessary to consider all the implications of processor, network, and interconnection 
possibilities possible with the USB 14, some of which are set out in the 
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Specifications, Vernon 1.0. For most uses, however, die host 16 can be expected to 
be a personal computer (PQ. 

An data management unit or interface 20 in accordance with the invention 
couples the host 16 to the peripheral devices 10 and 12. The interface 20 is a control 

5 endpoint of a logical USB device, which device also comprises two interrupt 
endpoints, one each for the keyboard 10 and a PS/2 device 12 such as mouse, joystick, 
or keypad. Thus, the keyboard 10 and the PS/2 device 12 are passive in the sense that 
their states are provided only in response to USB 14 requests. 

A keyboard-processing capability 4 defines a legacy device interface module 

10 and supports the keyboard interrupt endpoint by pulsing the rows of the keyboard 10 
and scanning the columns of the keyboard 10 to detect held keys. While detecting 
held keys, the keyboard-processing capability 4 eliminates "ghost key" indications 
and performs debouncing functions. The interface 20 repeatedly performs these 
detection, "ghost key-, and debouncing functions at a configurable rate specified in an 

15 electrically-changeable data adaptation unit such as the illustrated serial EEPROM 24. 
Subsequent to successfully debouncing a combination of detected keys, the keyboard- 
processing capability 4 maps the vendor-specific keycodes of the detected keys to 
their corresponding Human Input Device (HID) values, which arc USB~5tandardized 
keycodes, using vendor-supplied tables stored in the serial EEPROM 24. In turn, the 

20 keyboard-processing capability 4 builds a Keyboard Input Report consisting of the 
HI D values and formatted according to USB descriptor information obtained from the 
serial EEPROM 24. PS/2 device processing capability 8 supports the interrupt 
endpoint by collecting data from the PS/2 device 12, processing this data, and making 
the data available to the host processing capability 6, which defines a host interface 

25 module. Similarly, where the PSA device requires or supports bi-directional 
communications or commands, the PS/2 device processing capability 8 processes data 
fiomthe host 16 and makes h available to the PS/2 device 12. The translation of data 
and communication protocols in either direction is accomplished as determined in 
data stored in the configuration table in the serial EEPROM 24. 

30 Host processing capability 6 manages data flow in interface 20. In parallel 

with the Iceyboardjvooessifig capability 4, a host-processing capability 6 warts for 
device data requests from (he host, and upon receipt of a request, determines whether 
the request is made to the keyboard endpoint or mouse endpoint If the request is fbr 
data fiotn the keyboard endpoint, (he host^prootrenig capability 6 responds to the host 

35 16 with any device reports (such as Ixyboaniii^rtpom or PS/2 devkxrepom) that 
are available. If the request Is for data from the mouse endpoint, the host-processing 
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capability 6 responds to the host 16 whh any mouse data which a mouse-processing 
capability 8 has assembled. If an old device report cannot be sent to the host fast 
enough, the host processing capability 6 accumulates the old report in a new report 
before transmitting the new report to the host 

5 In concert with legacy device processing capability 3, the host processing 

capability 6 also controls and assembles data from other I/O devices, and provides 
legacy support to interface with devices compliant with a wide variety of interface 
protocols, including one or more serial devices 7 (such as a mouse, joystick, or 
keypad), parallel devices 1 1 (such as modems, digital cameras, and printers), infra-red 

10 interface devices IS (such as printers, digital cameras, cellular phones, and pagers), 
SCSI devices 17 (sod* as CD-ROMs, disk drives, printers, and tape drives) and IDE 
devices 23 such as CD-ROMs and disk drives. In addition, using die reporting 
capabilities in die USB interface, die present invention can also notify the host 16 
when U SB-incompliant devices are coupled to the interface 20. 

IS FIG. 2 presents a hardware block diagram of the interface 20. Within the 

interfile 20 processing functions are acceptably performed by an 8051 core 22, a 
widely-used 8-bit microprocessor. Processing functions can also be performed 
specific-design RISC chip processor, and can be internal or external to the interface 
20. The microprocessor 22 capability is augmented by data storage circuits including 

20 registers 52, a 256 byte RAM 30, and a 4K ROM 32, employed " buffering, 
processing, and transferring data as described below. In one embodiment of the 
present invention, the rmcropcoccss a r 22 is internally clocked 

Several conventional circuit dements that need not be described in detail are 
incorporated in die interface 20. These Include a PS/2 Universal Synchronous/ 

25 Asynchronous Receiver Transmitter (USART) 34, for serial to parallel conversion of 
signals from the mouse device 12, for buffering, aid for para^ 
of signals to the mouse device 12. Hicy also include a assembler circuits 37 
comprising a Serial Interface Engine (SE) logic circuit 36 for communicating 
identification, synchronization, twmrKhrirr, and configuration data with die USB 14 

30 via a USB alow speed transceiver 38. In die illustrated embodiment, a internal dock 
generator 40 is used in synchromnng the microprocessor 22, SIE logic circuit 36, and 
USB slow-speed transceiver 38. 

The interface 20 also comprises a keyboard matrix engine 42 or keyboard 
scanty which provides ti» intent 

35 20 througfc row lines 44, cohmm tines 46, and emitting <Hocfe (LED) lines 48. In 
addition, die Interface 20 incorporates a core 
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22 communicates with the PS/2 USART 34, and a serial EEPROM interface 26, 
through which the 8051 core 22 communicates with the serial EEPROM 24. 
EEPROM 24 stores one or more parameter sets with configuration information and 
interface parameters such as the keyboard scan rate, keyboard debounce count, key 

5 code maps (which may be vendor-specific), vendor ID or parameters, default values 
for parameter sets or other data, and other information. Nominally, this information is 
stored in a configuration table, and is user-configurable. Under selectable command 
of one or more configuration switches via a configuration switch interface 55, the 
configuration table may be programmed into and read from ROM 32 in addition to or 

10 as an alternative to the EEPROM 24. Keyboard matrix engine 42 and processor 22 
also supports a remote wake-up feature whereby the keyboard 10 is activated when 
user input, such as a key depression, is sensed 

Serial EEPROM interface 26 is a synchronous data engine which captures 
digital data into 8-bit data bytes that for processing by the 80S! core 21 The serial 

15 EEPROM interface 26 shifts in data from data line SDAT using serial EEPROM 
clock reference (SCLK). The serial EEPROM interface 26 can operate in a transmit 
only mode or a bi-directional mode. The SCLK signal is the clock input for (he bi- 
directional mode, and is used to synchronize data transfer to and from the serial 
EEPROM 24. SCLK must remain in a logical high state for serial EEPROM 24 to 

20 continue operations in the transmit only mode. SDAT is used to transfer addresses 
and data into ami out of the serial EEPROM 24 when in tbe bt-cfitectional mode. 

FIG. 3 illustrates data transfer in the bwErectfonal mode for the serial 
EEPROM interface 26. Logical state changes in SDAT when the SCLK signal is 
logically high are reserved for data START and data STOP indication, which indicate 

25 the beginning and end ofa data package. SCLK is set logically low when data (in the 
form of logical state transitions) is transferred along data line SDAT. Timing and 
definitions for Ac parameters shown in FIO. 3 are described in Table 1. 

The serial EEPROM 24 supports four data transfer modes: byte write, page 
write random read, and sequential read Each of these data transfer modes begins 

30 with a data START indication, and cads with a data STOP indication. Each data 
transfer also comprises a control header, word address segment, and following each 8 
bits of transmitted data, an acknowledge indication. These data transfer modes are 
illustrated in FIGS. 4A4X 

Registers 52 serve as (be medium for communication of control, status, and 

35 data information between the 80S1 core 22 and the keyboard matrix engine 22, PS/2 
engine 50, and serial EEPROM interface 26. Although the interface 20 monitors the 
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keyboard 10 and moose 12 for data independently of control from the host 16, the 
interface 20 manipulates the LED lines 48 in direct response to commands it receives 
across the USB 14 from the host 16* 

FIG. 5 illustrates one example of the coupling between the interface 20 and the 
5 keyboard 10. The row lines 44 and LED lines 48 are outputs from the interface 20 
that attach directly to the keyboard 10. Eighteen row lines 44 are provided, labeled in 
ascending order from RD to R17 and representing rows 0 to 17, respectively, of the 
keyboard 10. In contrast to the row lines 44 and LED lines 48* the column lines 46 
are inputs to the mteifece 20 that arc each connected in parallel with one of the pull- 

1 0 up resistors 70 that arc tied to VCC of die Universal Serial Bus 14. 

A held key on the keyboard 10 causes a connection to be made between a 
unique combination of one of the row lines 44 and one of the column lines 46, Upon 
command from the 8051 core 22, the keyboard matrix engine 42 sequentially pulses 
the row lines 44 in ascending order while simultaneously g«mnf Pg the column lines 

15 46 for each of the row lines 44 that is pulscdL If the keyboard matrix engine 42 
detects any held keys for one of the row lines 44, it stops pulsing the row lines 44 and 
notifies the 8051 core 22 through die registers 52 that scanning has been completed. 
In addition, the keyboard matrix engine 42 records in one of the registers 52 the row 
number of the last of the row lines 44 to be poised as well as sets a bit in another of 

20 the registers 52 for each of the column lines 46 tiiat were activated for the last of the 
row lines 44 to be pulsed. If die keyboard matrix engine 42 does not detect any held 
keys for any of the pulsed row lines 44, the keyboard matrix engine 42 records a value 
of 18 in the one of the registers 52 whose value represents the last of the row lines 44 
to be pulsed. Every time that the 8051 core 22 signals the keyboard matrix engine 42 

25 to scan die keyboard, die keyboard matrix engine 42 begins pulsing with die next of 
the tow lines 44 in ascending order that follows the last of the row lines 44 to be 
pulsed If the row corresponding to the last of the row lines 44 to be pulsed Is 
indicated as row 1 8, die keyboard matrix engine 42 begms pulsing with RO. 

Scanning the column lines 46 can result in indications that keys are held when 

30 in fiact the keys are not held. These "ghost key" conditions arise when dure or more 
keys arc held at (he same time in ^ If two keys are 

held in the same row, a third key is held in the same column as one of die first two 
keys, and the third key is held in a differently numbered row than (he first two keys, 
die connections that the first two keys make will provide two paths for a pulse 

35 generated en the row line corresponding to the row In which the third key Is located. 
One of the two paflis correctly indicates that the third key is held The other path 
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incorrectly indicates that a fourth key is held in the sane row as the third key and the 
same column as the other of first two keys that is not in the same column as the third 
key. 

The flowchart depicted in FIG. 6 presents an overview of the operations 

5 performed by the present invention. These operations are performed by the firmware 
of the 8051 core 22. After power-on, a self-test is run on the ASIC circuit units 
implementing the presort invention. As depicted, in block 80, the system next 
determines whether the ASIC self-test successfully completed and whether a fault was 
detected. If die ASIC self-test did not complete successfully or a fault was detected, 

10 firmware operations are halted with an unrecoverable error, as depicted in Mock 82. 
Otherwise, block 84 initializes hardware interfaces and firmware attributes. 

For purposes of illustration, FIG. SB is a flow chart showing the initialization 
operations performed for a PS/2 compliant device such as a mouse. First, the PS/2 
device receives 200 a power on and reset when powered on. If the PS/2 port is 

15 enabled 202, the PS/2 power line is turned on 204. After the elapse of a suitable 
period of time, the PS/2 device 12 enters the "ready" state 206. Next a series of self 
tests are performed in the PS/2 device 12. If the "AAJT self test completion code is 
not received 208 after a 1500 millisecond timeout 210, a reset command is issued 212 
to the PS/2 device by transmitting 314 the hex code FFH, thereafter returning to the 

20 PS/2 ready state 206. If the AAH self-test code has received^ the interface 20 next 
checks for the 00H self test code. If the proper code is received within 4 milliseconds, 
the PS/2 devices should be enabled 220, and the interface 20 enables the device by 
transmitting 222 a F4H code to the PS/2 device t2. If the proper code is not received 
within 4 ™niu»*»m/fc the PS/2 device 12 is reset as described above. The PS/2 

25 device acknowledges receipt of (he enable signal by trans mi tti ng a FAH code. The 
interface 20 awaits this signal tiff a period of 4 milliseconds as shown in block 22. If 
tbcackircwkdgesigr^B 

issued 212 to the PS/2 device 12. Iftbe acknowledge signal is received 224 within fee 

4 millisecond interval, toe PS/2 device eaters the idle stale 228. 
30 Returning to FIG. 6A, following initialization of hardware interfaces and 

firmware attributes, block 86 checks whether the interlace 20 has received a control 

endpoint SETUP transaction from the host 16. If the interface 20 has not received, a 

control endpoint SETUP transaction from the host 16, control is passed to block 90. 

If the irrterfece 20 has received a control endpoint SETUP transaction from the host 
35 1 6, Mock 88 calls the PROCESS_SETUP process and upon return from that process 

passes control to Mock 90. 
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Block 90 checks whether the interface 20 has received a control endpoint OUT 
transaction from the host 16. If not, block 90 passes control to block 94. If so, block 
92 calls the PROCESS_OUT_CNTL process and upon return from that process passes 
control to block 94. Similarly, block 94 checks whether the interface 20 has received 

S a control endpoint IN transaction from the host 16* If not, block 94 passes control to 
block 98. If so, block 96 calls the PROCESS JNCNTL process and upon return 
from that process passes control to Mode 98. 

Block 98 determines whether it is time to scan the keyboard 10 for held keys 
based op the configurable scan rate stored in die serial EEPROM 24. If his not time 

10 to scan the keyboard 10 for held keys, block 98 passes control to block 102. If it is 
time to scan the keyboard 10 for held keys, block 100 calls the SCANKB process 
and upon return from that process passes control to block 102. 

The SCANKB process 100 oversees the scanning of the keyboard 10 and 
performs debouncing functions in the present invention. Each invocation of the 

15 SCAN JCB process 100 results in one pass through die aU of the rows of the keyboard 
10 to scan for held keys. Debouncing determines if the same combination of keys is 
held for a configurable number of passes and thereby eliminates spurious keystroke 
indications. The number of passes required to ddxmncc a key is hereafter referred to 
as the debounce count Additional operations performed by the SCAN_KB process 

20 arc described with reference to FIGS. 7, 8A, and 8B herein. 

Block 102 decks whether a mouse error has occurred If not, block 102 
passes control to block 106. If so, block 104 calls the 
HANDl£MOUSE_ABNORMAL process and upon return from that process passes 
control to block 106. 

25 Block 106 determines whether a device address has been assigned. If not, 

block 106 passes control to block 80, which performs an ASIC self test If a device 
address has been assigi^ block 108 detcr^ 

new data. If the mcmse port has Mt received new 108 passes control to 

block 112 to check for a mouse endpoint stall condition. If the mouse port has 

30 received new data, block 1 1 0 calls the GBTMOUSEJDATA process and upon return 
from that process passes control to Mock 112. 

Block 112 checks whether a mouse endpoint STALL has occurred. If so, 
block 112 passes control to block 122. If not. Mode 114 determines whether the 
mouse has received new data. If the mouse has received new data. Mock 1 14 passes 

35 control to Mode 120. Ifthe mouse has not received throe new bytes of data, block 114 
passes control to Mode 116. 
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FIO. 6C is a flow chart further illustrating the steps performed to measure the 
<lata from the mouse or other PS/2 device 12. First, the PS/2 device 12 leaves the idle 
state 230 when it receives 232 a first byte of data. If no data is received for 50 
milliseconds, a PS/2 reset command is issued 236. If data is received, it is loaded 238 
5 in a PS/2 buffer, and the interface writs 4 milliseconds for second byte of data fiom 
the PS/2 device 12. This is depicted in block 242, If the data is not received within 
the 4 millisecond interval, a PS/2 reset command issued 244. If a second byte of data 
is received, it is loaded 246 in the PS/2 buffer, and die interface again waits 4 
milliseconds for the third and last byte of data from the PS/2 device 248. When that 

to data is received, a USB report is prepared using the three bytes of device data in the 
PS/2 buffer. This is depicted in Modes 256 and 254. The foregoing technique, which 
is especially useful in interfacing with low-bandwidth devices, essentially accepts data 
from the PS/2 device 12 in smaller increments at multiple intervals. This technique, 
the present invention reduces memory and processing requirements, and maximizes 

15 the adaptability of the interface 20 to a wide variety of devices. For example, the bh 
length and number of data packages accepted by the interface 20 can be user selected 
via programming the configuration table or configuration switches as desired. 

Returning again to FIO. 6A, Block 116 checks whether die event flag 
MOUSE JDLEJELAPSE has been set If not, block 1 16 passes control to block 122. 

20 If so, block 118 reloads the mouse idle timer, clears the MOUSE JDLE_ELAPSE 
event flag, and passes control to block 120. Block 120 calls the 
I IANDLE JN JNIK(MOUSE) process to respond to any host request for mouse data, 
and upon return from that process passes control to block 122. 

Block 122 checks whether a keyboard endpoint STALL has occurred. If so, 

25 block 122 passes control to block 84. If not, block 124 determines whether any new 
key has been p ressed. If a new key has been pressed, block 124 passes control to 
Mock 130. If a new key has not been pressed, block 124 passes control to block 126. 

Block 126 checks whether the event flag KBJDLE_ELAPSE has been set If 
not, block 126 passes control to Mock 84. If so, block 128 reloads the KB idle timer, 

30 clears KB JDLEJELAPSE, and passes control to block 130. Block 130 calls &e 
HANDLE JNJNTR(KB) process to respond to any bost request for keyboard data, 
and upon return fiom that process passes control to block 84. 

FIG. 7A is a flowchart showing the SCAN _KB process 100. This is the main 
process by which the firmware manages the operation of the keyboard. This process 

35 is called every time the uscr-defined scan period expires. 
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At Ac start of the SCAN_KB process, block 301 is called to in initialize the 
OldJScan value to -1 (the purpose of initializing the OldJJcan value to -1 is to 
prepare die keyboard scanning process to begin at the starting row, Row 0). Block 
302 enables the KB engine to start the actual KB scanning routine. Each time the KB 

s engine scans 303 the keyboard, it will process from row 01d_Scan to a row which has 
detected a key pressed or until h reaches row 18. Row 18 is a logical row that the 
firmware looks at to check for the completion of the keyboard scanning. Upon the 
completion of one keyboard scan, the current row number is stored 304 and its 
column is read 30S. Then, block 306 is called to determine the status of the 

10 SCANJCB process. If the SCAN_KB has not completed its scanning routine up to 
the last row, then block 307 is invoked to save the current row and column results. 
Next, block 308 is called to check if the scan of pressed key is a first time event If 
the result is not a first time event, then block 309, (DEBOUNCECHECK_ #1), is 
called to check for the stability of the pressed key(s). Block 310 updates the 

15 OldJScan value to the current row number which will indicate (he beginning of the 
next keyboard scan, and block 311 is invoked to compare the content of the current 
row with the previous row and save only the stable key events. Afterward, die KB 
engine is enable to begin another key scan routine. If block 308 determines that this is 
the first scan of die current row, then debounce check is not required ami the 

20 KB_SCAN routine continues to scan its next row, 

FIG. 7B is a flow chart describing the DEBOUNCE_CHCK_ #1 process. In 
this case, die KB engine has already scanned die keyboard at least once. The 
firmware starts at the row prior to NewJJcan as shown in block 334, and ends at row 
Old_Scan, clearing oat any key detected before but not during tins scan session. This 

25 process is flhstrated in blocks 336 and 337. 

Returning to FIG. 7A, once die last row has been scanned in the SCANJCB 
process and (he debounce checking has been completed up to the very last row, the 
debounce count value is decremented by one. This is illustrated in blocks 312, 313, 
and 314. If Oris count is not rcro, 315 then SCANJCB returns to the idle state of the 

90 KMP process until Hb called again. If (he count is xero, however, the firmware will 
prepare (he data to be seat to die host in the following processes of 
CHKJCBJMJFFER 316 and CQMPJBD.BUFFER317. 

FIG 7C shows (he operations perfor m ed with respect to (he 
aOCKB^BUFFER process 316. The CHKKBJJUFFER process at block 316 is 

35 called to process key pressed event For die raw with a key press d et ected, die 
firmware will check from column 0 and up to column 7 to determine the exact 
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location of the pressed key. This is illustrated in blocks 338-343. Once the column 
location of the pressed key is detected, block 348 will determine if ghost key checking 
is required. If no ghost key checking is needed, the firmware will proceed to invoke 
the process MAP_KEYCODE in block 350. The MAPJCEYCODE process 350, 

s to be discussed later, returns with a determination of whether or not there is a phantom 
state condition in the key event The firmware will then simply indicate whether or 
not there is a phantom state 351 and proceed to process die next column beginning 
with block 342* If ghost key checking is required, the CHKJ3HOSTKEY at block 
353 is called to fill the HID buffer with 0's for the modified key location and V s for 

10 the normal key locations. A discussion of the CHKJ3HOSTJCEY process 3S3 is 
prese nt e d herein. 

When firmware has completed its checking of die current row at all of its 
column locations, block 344 is called to continue the checking of the next row. Block 
345 is involved to see if the firmware has readied die last row. If the firmware has 

15 checked die last row, then block 346 is called to see if a phantom state or overflow 
condition exists. Normally, the phantom condition is one in which there is more than 
six allowable normal pressed keys bong detected. The number of detected lays 
constituting a phantom condition may be user-definable using die EEPROM 24, other 
memory 30, 32 or the configuration switch 55. If phantom condition exists, then the 

20 firmware will report Ts for the normal HID key buffer location 347 and then return to 
the SCANKB; otherwise, block 347 is skipped and die firmware wfll return to 
SCANJKB 100 and call the process COMPJIIDBUFFER 317. 

FIO. 7D shows the operations performed with respect to the 
MAP JCEYCODE 350 process. In the MAP_KEYCODE process 350, the firmware 

25 first calculates 356 the key code offset and then branch to another process called 
READ.EEPROM 357 to retrieve the actual HID key code value. Once the HID key 
value is obtained 358, block 359 is called to look for the prese nce of any modified 
key. If there is modified key, the firmware wffl calculate 

scanned and the result is saved 316 to the first byte of the HID Buffer. If there is no 
30 phantom stale or key overflow condition, the firmware will set a flag to indicate no 
phantom state and return to the SCANKB process. On the other band, if there fa no 
modified key present, then the firmware will proceed to process the normal key 
routine. During this normal key processing, there will be checks to make sure so 
phantom state exists 363. If there is phantom state, block 364 is called to indicate thst 
35 phantom state exists and returns the process to the SCANJCB. tf there is no phantom 
state, then the HID Key code is caved into byte locations 2 through 7 of the HID 
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Buffer and then retains to the SCAN_KB process which then calls the process 
COMP JBH) JBUFFER 3 1 7. This is shown in block 365. 

FIG. 7E illustrates the operations performed with respect to the 
CHECK^GHOSTJKEY process 353. When the CHECK_GHOST_KEY process in 

5 block 353 is called from CHK_KB_BUFFER 3 16, the firmware will analyze the KB 
BUFFER that contains the keyboard data In that buffer a to w with at least two keys 
pressed will be isolated to observe for possible cause of ghost key condition. 
Whenever a row has al least two keys pressed and their column location matches with 
the column of anqther row's pressed key, a ghost key condition has occurred The 

10 process of checking for ghost key condition begins with storing 366 the value of the 
row in question 367 in a temporary register, then the row's value is cleared from the 
KB BUFFER. Starting at the beginning 367 of the buffer and incrementing 370 up to 
the end, each row's value is compared 369 to the temporary register for ghost key 
condition. If there is a ghost key condition, thai a flag is set to indicate 373 so and 

IS the process returns to CHK_KB_BUFFER to continue on to block 354, If no ghost 
key condition is found, then the value of the row in question in the KB BUFFER is 
restored 372, and the flag will indicate no ghost key condition before also returning to 
the CHK_KB_BUFFER process. 

FIG. 7F illustrates the operations performed with respect to the 

20 OOMPjnDJJUFFER process 317, When CHK_KB_BUFFER 316 has completed 
the SCANKB 100 process continues on to the process COMPJfflDJBUFFER 317. 
This process basically compares the HID value from the current keyboard scan to the 
HID value from the previous keyboard scan to determine whether or not there are any 
new key events. Starting at the beginning 374 and working towards the end of the 

25 buffers, the firmware reads 375 the current HID value from the HID BUFFER and 
compares 376 it to the old HID value in (he OLD_HID BUFFER. At the same time, 
the current HID values are updated 37S into the OLDJfUD BUFFER, getting it ready 
for the next call of foe COMP_HID_BUFFER 3 1 7. After the comparison is done, the 
Debotmce count is loaded and the KB J3UFFER factored 380. 

30 FIG. 8 fa a flow chart depicting the serial interface operations performed by 

one embodiment of the present invention. In the illustrated example, the serial 
intefece device is ft modem. Supported functions include initializing the U ART, 
receiving data from the host via USB port and transmitting data out to the modem via 
the serial interface port, and transfer them to host through USB port, receive call 

35 management commands from the USB host and convert them to AT commands and 
send them to the modem through the serial taterfiee port 
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After the modem has been configured in block 4 1 4 by setting up the baud rale, 
data bits, and start/stop bit, (he interface 20 can receive call/device management 
commands from tbe USB compliant device or host, as depicted in Wock 410. These 
commands arc converted into AT commands in block 412. The interface 20 sends the 

5 AT commands to the modem by configuring the transfer mode and initiating a transfer 
buffer pointer as depicted in blocks 418 and 420. Next, bytes of information are read 
or written 422 and the buffer pointer 424 is updated 424 until the end of the buffer is 
reached 426, thus transmitting the entire string byte by byte until the entire command 
string is transmitted as shown in block 428. 

10 Whenever the USB host has data to be transferred to the modem 402, the 

interface 20 receives data from the host 406, through the USB port 14 until a block of 
data has been transferred 408. The transfer mode is then configured into a "data 
mode" as shown in block 4 1 8, initialize die transfer buffer po inter 420 , write data byte 
by byte in blocks 422 424 and 426 until done 428. 

15 When the interface detects a new event on (he serial port 404 and 406, if it is a 

request for inward data, transfer from the modem 432, the interface receives by 
configuring the transfer mode 418 to u data mode," initialize the transfer buffo: pointer 
420, and read data byte by byte, as described above. The keyboard could also notify 
the USB host through an interrupt pipe, as shown in block 434 when a serial port 

20 event occurs 405. 

Finally, the when fee USB host requests 403 , interface 20 transfers data back 
to the USB host through bulk b or isochronous in {ripe as shown in block 403 436, 
and 438 until completed 428. 

FIG. 9 is a flowchart depicting the parallel interface operations performed in 

25 one embodiment of the present invention* The operations supported include coupling 
the processing unit with a parallel port, receiving data from the host through the USB, 
sending data to a parallel port interfice device On the example shown, the device is a 
printer), receiving device/interlace commands from the USB host, sending those 
commands to the printer, and forwarding primer responses to the USB host 

30 After the printer has been initialized as shown in block 500, and whenever the 

host has data to be printed as shown in block 502, the interface 20 receives data from 
the host as depicted in block 504 through a USB pott until a block of data has been 
transferred 506. Tbe interfile 20 (ben configures the primer port 510 and starts to 
output tbe data to the parallel port as shown in block 512. After the data transfer is 

35 completed, tbe printer status is seat back 5 14 to the interface 20 which then sends the 
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printer status back to the host in block 518 through a USB port when the host requests 
it as shown in block 522 or 523. 

If the USB host requests any information fiora the printer 504, the interface 20 
sends the response to the host in block 5 1 8 if it already has the printer information as 
5 shown in block 514. If the interface 20 does not have the requested updated 
information 526, it will send the commands to the printer as shown in block 512, 
receive the response as shown in block 514, and forward the information to the host as 
shown in blocks 516, 518, and 520. 

When the USB host needs to output 528 configuration data to the printer, the 
10 interface 20 receives 530 device/interface commands from the USB host, send the 
command to the printer as shown in block 512, receive 130 the printer status and send 
the status back to the host as shown in blocks 516, 518, and 520. 

FIG. 1 0 is a flow chart depicting the operations performed in using the present 
invention with an infra-red peripheral device. In the example shown, supported 
1 s operations include receiving image data from a camera through an infra-red (IR) port, 
transmitting data comprising the images to the USB host through die USB port, 
receiving setup commands from the USB host, converting the setup commands to IR 
energy commands of die proper protocol, end sending the IR commands to the 
camera. 

20 When the USB host sends 600 a setup command, it is received 602 in Ac 

interface 20. If the interface 20 already has the camera information, block 604 routes 
processing to block 606, where the response is sent bade to the USB host Otherwise, 
the interface 20 converts 61 0 the command to an appropriate IR command, and sends 
612 the command to the camera via the IR port. The interlace 20 then receives 614 

25 the camera's response or status, translates it if necessary (using interface configuration 
data) and forwards 606 it to the USB host 

After die interface 20 U initialized 616, the data transfer rate is set up 618, and 
the interface 20 det ects 620 an event from the IR port requesting a data transfer, the 
port is configured 622. Next, the buffer pointer is initialized 624. and the data is read 

30 byte by byte from the IR port in blocks 626 and 628 until all of the data is read 630. 
Finally, the when the host requests 632, the interface 20 starts transferring 634 image 
data back to die host through the USB port, and continues until all of flic data is 
transferred, as shown in blocks 636 and 608, 
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conclusion 

A low cost, highly adaptable system and method for interfacing a wide variety 
of input devices to a host employing the USB interface is disclosed This interface is 
particularly wdl suited to adapt existing keyboards and mouse input devices to host 
computes operating with the USB protocol The interface includes a degree of 
processing capability and a memory capability, allowing vendors to customize the 
interface to implement many interface protocols and processing schemes. 
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what ts CLAIMED 15s 

1. A method of adapting at least one USB-incompliant device to a USB- 
compliant device, comprising the steps of: 

defining a first USB endpoint for a first USB-incompliant device and a 
5 second USB endpoint in an interface in accordance with a first interface parameter set 
storaWe in a memory in the interface, the interface coupled to the USB-incompliant 
device and the USB compliant device; 

reading data from the first USB-incompliant device in the interface; 
preparing a device report comprising the first USB-incompliant device data; and 
10 providing the device report to the USB-compliant device via the first USB endpoint 
when a first USB-incompliant device data request is received by the control endpoint 

2. The method of claim 1 wherein the first USB endpoint is an mtemzpt 
endpoint and the second USB endpoint is a control endpoint. 

3. The method of claim 1, further comprising the step of notifying the 
1 5 USB compliant device when a USB-incompliant device is coupled to the interface. 

4. The method of claim 1, wherein the first interface parameter set 
includes a table for transforming USB-incompliant device data into USB-compliant 
device data. 

5* The method of claim 1, wherein the first interface parameter set 
20 comprises a default interface parameter* 

6. The method of claim 1, wherein the memory is a uscKonfigurablc 
non-volatile memory. 

7. The method of claim 1, wherein the interface parameter set is 
sclectably designated by a configuration switch. 
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8. The method of claim 1, farther comprising the steps of: 

accepting & command for the first USB-incompliant device in the 
interface from the USB-compliant device; 

translating the command into a USB-incompliant device command in 
5 accordance with the first interface parameter set; and 

transmitting the USB-incompliant device command to the USB- 
incompliant device. 

9. . The method of claim 1, wherein the first USB-incompliant device is a 
keyboard comprising a matrix of key positions defined by intersecting row lines and 
column lines, and the Step of reading data from the keyboard comprises the step of 
sequentially pulsing the row lines while scanning the column lines for each row line 
that is pulsed; 

suspending pulsing of the row and column fines when a key position is 
detected as held; 

reading the row line and column line corresponding to the held key in 

the interface; 

storing die last row line pulsed in a second memory; and 
resuming pulsing the row lines from the last row line pulsed 

10. The mediod of claim 9, wherein the interface parameter is selected 
20 from flic group comprising a keyboard scan rate, a keyboard debounce count, a 

keyboard key code map, and a vendor identification parameter. 



10 



is 



11. The method of claim 9 whetein die interface parameter set comprises a 
keyboard keycode map and the method further comprises die step of translating the 
row Kne and column line indications into a keyboard input report using the keyboard 
25 keycode map. 



12. The method of claim 9 further comprising the steps of: 
comparing a plurality of successive row and column lines; 
transmitting die row and column lines to the control endpoint only 
when successive row and column lines match. 

30 
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13. The method of claim 12, vdicrdn the interface parameter set comprises 
a keyboard denounce count defining a number of successive row and column numbers 
compared. 

14. The method of claim 1, wherein the interface is further coupled to a 
second USB-incompliant device and the method further comprises the steps of: 

defining third an USB endpoint for the second USB-incompliant 
device in accordance with a second set of interface parameters stored in the memory 
in the interface, 

reading data from the second USB-incompliant device in the interface 
via the third USB endpoint; 

preparing a device report comprising the second USB-incompliant 
device data; and 

providing the device report to the USB-comphant device when a 
second USB-incompliant device data request is received by the second USB endpoint 

15. The method of claim 14, wherein the third USB endpoint is a second 
interrupt endpoint 

16. The method of claim 14, wherein the second USB-incompliant device 
comprises a PS/2 device, and die step of reading data from the second USB- 
incompliant device comprises the steps o£ 

segmenting the data from the second USB-incompiiant device into data 

subsets; and 

successively reading data subsets from (he PS/2 device and storing the 
data subsets in a buffer inemoiy in die interface. 

17. The method of daim 14 wherein the second USB-incomptiant device 
is a serial data transfer device. 

18. The method of claim 14 wherein the second USB-incomplinnt device 
is a parallel data transfer device. 
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19. The method of claim 14 wherein the second USB-incompliant device 
is an infrared data transfer device. 

20. A method of communicating data between at least one USB-compliant 
device and a first USB-incompliant device comprising the steps o£ 

sending a message requesting a device report from an interface coupled to a first 

USB-compliant device and the USB-incompliant device, the interface defining a first 

USB endpoint and a second USB endpoint tor the first USB-incompliant device in 

accordance with a first interface parameter set stored ma memory; and 

receiving the device report from the mterface,vto the first mtenuptendpom 

the device report is prepared by performing the steps of reading data from the first 

USB-incomptiant device in the interface. 

21. The method of claim 20, further comprising the step of receiving a 
message mdicating that a USB4ncomplianl device is coupled to the interface, 

22. The method of claim 20, further comprising the step of sending a 
message to the interface to command the first USB-incmnplianl device, the message 
translated into a USB-incompliant device command in the interface in accordance 
wm the first interface parameter set 

23. A method of adapting a USB-ineomplinnt device to a USB-compliant 
devi<*» comprising the Steps of. 

reading a command from the USB-compliant device in an interface 
coupled to the USB compliant device and the USB-tacompliant device, the interface 
definmgafjrstUSBendpoimcotnmm 

transforming the command to a USB-incompliant device command in 

tccordnjcevvhbanteterfiwi^ 

transmitting me transformed command to the USB-incompliant device. 



24. The method of claim 23 vvherein the first USB endpoint is a control 
endpoint and me second USB endpoint is an mtemnrt endpoint. 
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25. An apparatus for adapting at least one USB-incompliant device to a 
USB-compliant device, comprising: 

means for defining a first USB cndpoint for a first USB-incompIiant 
device and a second USB cndpoint in accordance with a first interface parameter set 
5 stored in a memory accessible by the interrupt endpoint; 

means for reading data from the first USB-incompliant device; 
means for preparing a device report comprising the first USB-incompliant device 
data; and 

means for providing the device repent to the USB-compliant device 
10 when a first USB-incompliant device data request is received by the second cndpoint 

26. The apparatus of claim 25 wherein the first USB endpoint is an 
interrupt endpoint and the second USB endpoint is a control endpoint 

27. The apparatus of claim 26, further comprising means for notifying the 
USB-compliant device when an interrupt endpoint for a first USB-incompliant device 

is is defined. 

28. The apparatus of claim 25, wherein the first interface parameter set 
includes a table for transforming USB-incompliant device data into USB compliant 
device data. 

29. The apparatus of claim 25, wherein the memory is a user-configurable 
20 non-volatile memory. 

30. Hie apparatu s of clam 25, wherein the interface parameter set is 
selectably designated by a configuration switch. 

31. The apparatus of claim 25, further comprising: 

means for accepting a command for the first USB-incompliant device from the USB- 
25 compliant device; 

means for translating the command into a USB-incompliant device 
aHnmawiinBcconiara* 
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means for transmitting the USB-incompliant device command to the 
USB-incompliant device. 

32. The apparatus of claim 26, wherein the first USB-incompliant device is 
a keyboard comprising a matrix of key positions defined by intersecting row lines and 
column lines, and the means for reading data from the keyboard comprises: 

means for sequentially pulsing the tow lines while scanning down the 
column lines for each row line that is pulsed; 

means for suspending pulsing of the row and Column lines when a key 
position is detected as held; 

means for reading the row line and column line corresponding to the 

held key; 

means for storing the last row line pulsed; and 
means for resuming pulsing the row lines ftom the last row line pulsed. 

33 . The apparatus of claim 32, further comprisi ng means for translating the 
row and column tines into a keyboard input report using a keyboard keycode map 
stored in the memory. 

34. The apparatus of claim 32, further comprising: 

means for comparing a plurality of successive row and column lines; 

and 

means for transmitting the row and column lines to the control 
endpoint only when the successive row and column lines match, 

35. The apparatus of claim 34, wherein the interface parameter set 
comprises a keyboard debotmce count defining a number of successive row and 
column numbers compared. 

36. An apparatus for adapting at least one USB-incompliant device with a 
USB-compliant device, comprising; 

a legacy device interface module, communicatively coupled to the firrt 
USB4ncompliant device, Ae legacy device interfcbe module defining a first USB 
endpoint for the first USB-incompliant device, the legacy device interface for 
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obtaining data from the first USB-incompliant device and for generating a report 
comprising USB-incorapliant device data; 

a host interface module, in an interface coupled to die USB-compliant 
device and the legacy device intcrfece module, the host interface module defining a 
5 second endpoint, the host interface module for generating a USB-compliant data 
report comprising USB-incompliant device data; and 

a user-configurable memory coupled to the legacy device interface 
module and the host intcrfece module, fir storing interface parameters for the first 
USB endpoint and the second endpoint and for generating (he USB data report 

10 37. The apparatus of claim 36, wherein the first USB endpoint is an 

interrupt endpoint and the second USB endpoint is a control endpoint 

38, An interface device, comprising? 

a processor, communicatively coupleable to a user-configurable 
memory via a user-configurable memory interface, and a USB-compliant device via a 
15 USB transceiver, wherein themser configurable memory comprises a configuration 
table storing data defining interface parameters for the USB-compliant device and a 
USB-incompliant device; 

a keyboard scanner, communicatively coupled to the processor and 
communicatively coupleable to a keyboard comprising a matrix of key positions 
20 defined by intersecting row lines and column fines, the keyboard scanner for 
sequentially pulsing the row lines while scanning the column lines for each row line 
that is pulsed; and 

wherein the pro ce ssor comprises means for generating a USB report 
comprising data from the keyboard. 

25 39. The interface of claim 38, further comprising a peripheral device 

scanner, comprising a peripheral device transceiver communicatively coupleable to a 
USB-incompliant peripheral device and a peripheral device engine for providing 
communications between the processor and tbe peripheral device transceiver. 

40. The inte rfa ce device of claim 38, further comprising a configuration 
30 switch interface, coupled to tbe processor, for selectably ^p^g interface 
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41. A system for enabling peripheral units which may have widely 
different operating characteristics, including but not limited to data rate, 
synchronicity, data format, directionality, and mode of operation, to be coupled 
without modification to a universal serial bus host which requites prescribed data 

s piescriptoxs and presented data formats, but without requiring changes in die host for 
different peripheral unit configurations, comprising: 

a data management unit including an internally clocked microprocessor 
having data storage circuits and coupled to receive data in the form and at times 
provided by the different peripheral units,. and having assembler circuit coupled to 
10 provide universal serial bus message frames to the host on demand; 

an dectromcally-diangcablc data adaptation unit including circuits for 
storing particularized configuration data as to peripheral unit properties, including 
data prescriptors, data formats, and interchange protocols, and coupled to control both 
the timing of transfer and the transformation of received data into universal serial bus 
15 format in die data management unit, whereby different peripheral units can be coupled 
to function with the host by changing only the data adaptation unit 

42. The system of claim 41 above, wherein the data adaptation unit 
comprises an electronically erasable programmable read only memory. 

43. The system of claim 42 above, wherein die host operates an active 
20 command bus structured to control endpoints representing slots for different 

peripheral units, and wherein the system is arranged to function as a control endpoint, 
with different interrupt endpoints for the different peripheral units. 

44. The system of claim 41 above, wherein the peripheral unit is a 
keyboard comprising a matrix of key positions defined by intersecting row lines and 

25 column lines, and the data management device comprises means for reading data from 
the keyboard, comprising: 

means for sequentially pulsing the row lines while scanning down the 
column lines for each row line that is pulsed; 

means for suspending pulsing of the row and column lines when a key 
30 position b detected as held; 
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means for reading the row line and column line corresponding to the 

held key; and 

means for resuming pulsing the row lines from the last row line pulsed 

45. The system of claim 44 above, further comprising: 

means for comparing a plurality of successive tow and column lines; 
means for transmitting the row and column lines to the control 

endpoint only when the successive row and column lines match; and 

wherein the data adaptation unit stores data defining the number of 

successive row and column numbers compared 
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